Part of #712

Things done

• Change to enable the flag when the rollout starts (Only if the flag is disabled)
• Check if the rollout has already stopped before proceeding
• Refactored the code to update the progressive rollout and the feature flag in the same transaction to avoid race conditions nad unnecessary audit logs
• Updated tests

This pull request introduces several changes to the pkg/autoops/api/ package in order to improve the handling of progressive rollout status, add checks for stop status, and refactor the code to simplify the logic and improve readability. The changes also include updates to the test suite to reflect these modifications.

Error Handling and Status Checks:

• pkg/autoops/api/error.go: Added a new status statusProgressiveRolloutAlreadyStopped to handle cases where a progressive rollout is already stopped.
• pkg/autoops/api/progressive_rollout.go: Added a new method checkStopStatus to check if the progressive rollout is already stopped. This method is used in ExecuteProgressiveRollout.
• pkg/autoops/domain/progressive_rollout.go: Added a new method IsStopped to the ProgressiveRollout struct to check if the progressive rollout is stopped.

Code Refactoring and Simplification:

• pkg/autoops/api/progressive_rollout.go: Refactored the ExecuteProgressiveRollout method to use ftstorage.NewFeatureStorage and ftStorage.GetFeature instead of the previous approach. Also added checks for stop status and logic to enable the feature flag if it is disabled and it is the first rollout execution. [1] [2] [3]
• pkg/autoops/api/progressive_rollout_operation.go: Refactored the ExecuteProgressiveRolloutOperation and related methods to use ftdomain.Feature instead of featureclient.Client. Also simplified the logic to update the rollout strategy. [1] [2]

Test Suite Updates:

• test/e2e/autoops/progressive_rollout_test.go: Updated the tests to create disabled features and check if the feature is enabled during the progressive rollout. (F6f93751L15R15, [1] [2] [3]